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Abstract: 

This  is  the  fifth  report  of  a  series  exploring  the  use  of  the  £7  programming  notation  to  prototype  a  pro- 
gramming environment.  This  environment  includes  an  interpreter,  unparser,  syntax  directed  editor, 
command  interpreter,  debugger  and  code  generator,  and  supports  programming  in  a  small  applicative 
language.  The  present  report  presents  a  code  generator  operating  on  abstract  syntax  trees.  The  code 
generation  process  is  implemented  as  an  evaluator  over  a  nonstandard  domain.  An  implementation  of 
the  code  generator  is  listed  in  the  appendices. 


1.  Introduction 

Our  goal  in  this  series  of  reports*  I  MacLennan85b,  MacLennan85c.  MacLennan86a.  MacLennan86bi  is 
to  explore  in  the  context  of  a  very  simple  language  the  use  of  the  Q  programming  notation  [MacLen- 
nan83,  MacLennan85ai  to  implement  some  of  the  tools  that  constitute  a  programming  environment. 

In  this  report  we  define  a  code  generator  for  abstract  programs.  The  code  generator  will  be  a 
member  of  the  same  family  as  the  interpreter  and  the  unparser.  That  is.  it  will  be  an  evaluator  for 
abstract  programs  defined  on  the  domain  of  code  sequences.  First  we  discuss  machine  and  run-time 
structure;  next,  informal  translations;  and  finally  present  the  translation  rules. 

2.  Target  Machine  Structure 

We  will  generate  code  for  a  stack  machine  with  several  special  purpose  registers  ( EP.  SP)  and  several 
temporary  registers  (Tl.  T2).    It  has  the  following  instructions: 


Support  for  this  research  was  provided  by  the  Office  of  Naval  Research  under  contract  N00014-86- WR-24092. 


•  LDC  k  —    load  constant 

.  ADD,  SUB,  MUL,  DIV,  EQL,  etc.  -    arithmetic 

•  JMP  /,  JMPT  /  —    unconditional  jump,  jump  on  true 

•  LBL  /  —    define  label 

•  SKIP  6  —    skip  down  static  chain 

•  LOD  —    load  contents  of  variable 
.  ENTER,  EXIT  -    block  control 

.  CALL.  RETURN  -    function  control 

.  PUSH  r.  POP  r  -    stack  control 

•  BREAK  -    enter  debugger 

3.    Run- Time  Structure 

We  use  a  conventional  static-chain  implementation  for  statically-scoped  languages.  Note  that  this 
stack-based  activation  record  structure  will  not  support  function-valued  functions,  which  are  supported 
by  the  interpreter.  This  incompatibility  between  the  interpreter  and  code  generator  is  very  serious,  but 
not  addressed  in  the  present  report,  since  it  would  not  affect  the  use  of  H  as  a  tool  for  writing  the  code 
generator.  Exercise  for  the  reader:  define  a  non-stack-based  activation  record  structure  that  solves  this 
problem. 

Consider  the  following  program: 

ilet  A  =    1 
funcF  X  = 

|  let  B  =    ( X  x  A ) 
lletC  =    3 

(if  (X  >    0) 
then  F  (C  +    (X  -  B)) 
else  0  )  I 


F(Ax2)  ]] 

This  diagram  illustrates  the  run-time  data  structures  when  execution  is  within  the  'let  B  =    ...'  block  on 
the  recursive  invocation  of  F: 


-  EP 


Lh   -      f 


Notice  how  the  static  links  for  both  of  F's  activation  records  point  to  the  environment  denning  F.    The 
ep/ip  pair  is  the  dynamic  link. 
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4.    Informal  Translation  Rules 

4.1  Constants,  Variables  and  Applications 

For  constants  we  merely  stack  the  constant  value: 

k      =>      LDC  Jt 

For  variables  we  must  6rst  scan  down  the  static  chain  to  the  environment  of  definition  of  the  variable. 
Then  the  value  of  the  local  variable  from  that  environment's  activation  record  can  be  loaded  onto  the 
stack: 

SKIP<5 

v    =*     LOD 

where  6  is  the  static  distance  to  v's  activation  record. 

The  code  for  an  application  is  illustrated  by  this  example: 

X 

X+Y   =*>     Y 

ADD 

The  X  and  Y  on  the  right  represent  the  code  corresponding  to  the  X  and  Y  on  the  left.  Thus  we  gen- 
erate code  that  executes  A'  and  Y  in  order  and  leaves  their  values  on  the  stack,  where  they  can  be 
popped  by  ADD. 

4.2  Conditional  Expression 

Code  for  a  conditional  first  evaluates  the  condition,  leaving  a  Boolean  value  on  the  stack.  A  JMPT 
instruction  can  then  be  used  to  test  this  value,  skipping  the  alternate  and  jumping  to  the  consequent 
when  the  value  is  true. 


B 

JMPT  t 

(if   B 

F 

then    T       = 

=>      JMPu; 

else    F  ) 

LBL  t 

T 

LBL  uj 

Of  course  the  code  for  the  alternate  must  end  with  a  JMP  to  skip  the  consequent. 


4.3  Blocks 

The  first  step  in  the  code  for  a  block  is  the  evaluation  of  the  bound  value  E  in  the  surrounding  con- 
text. Two  macro  instructions,  ENTER  and  EXIT,  surround  the  block  body  B,  and  handle  the  entry  and 
exit  of  the  block  context: 

E 

let.  =  ^  ENTER 

B  ]  "*     B 

EXIT 

The  ENTER  macroinstruction  must  create  the  block's  activation  record,  incorporating  the  bound  value. 
and  link  the  activation  record  into  the  static  chain.    It  is  equivalent  to  the  following  operations: 

PUSH  EP       {SL} 
EP-SP  {setEP} 

That  is,  we  push  the  old  value  of  the  EP  register  (which  is  a  pointer  to  the  surrounding  context)  onto 
the  stack,  thus  forming  the  static  link  of  the  new  activation  record.  The  value  of  the  bound  value  E  is 
already  on  the  stack,  where  it  will  be  accessible  as  the  local  value  in  the  new  activation  record. 
Transferring  the  contents  of  the  stack  pointer  (SP)  to  the  environment  pointer  (EP)  installs  the  new 
activation  record  as  the  active  one. 

The  EXIT  macroinstruction  must  save  the  value  computed  by  the  block  (which  is  on  the  top  of  the 
stack)  while  the  block's  activation  record  is  deleted.    Its  code  expansion  is  straight-forward: 

POPTl  {block  value} 

POPEP  {SL} 

POP-  {local} 

PUSH  Tl  {block  value} 

4.4  Function  Definition 

Consider  a  function  definition  such  as  the  following: 

[func  /  n  =  B 

X\ 


This  is  very  much  like  a  let  block,  except  that  execution  of  the  function  body  B  must  be  deferred  until 
the  function  /  is  invoked: 

JMP  uj  {skip  function  body} 

LBL  <t>  {entry  point} 

B  {body  of  function} 

RETURN  {return  to  function} 

LBL  uj  {here  to  skip  function  body} 

LDC  4>  {stack  entry  point} 

ENTER  {enter  func.  defn.  block} 

A'  {body  of  func.  defn.  block} 

EXIT  {exit  func.  defn.  block} 

The  function  body  is  represented  by  the  LBL  <f>  (which  is  its  entry  point),  the  code  B.  and  the 
RETURN  macroinstruction  (which  is  discussed  below).  The  JMP  w  skips  the  function  body,  thus 
deferring  its  execution.  The  LDC  0  stacks  the  entry  point  address  as  the  local  value  of  the  function 
block,  which  is  then  ENTERed  and  EXITed  in  the  usual  way. 

4.5    RETURN  Instruction 

The  RETL'RN  macroinstruction  has  the  task  of  saving  the  function's  value  (which  is  on  the  top  of 
the  stack),  restoring  the  caller's  environment,  deleting  the  function's  activation  record,  leaving  the 
function?  value  on  the  top  of  the  stack,  and  resuming  execution  of  the  caller.  The  code  to  accomplish 
this  is: 

POPTl  {return  value} 

POP  EP  {caller's  EP} 

POP  T2  {caller's  IP} 

POP-  {SL} 

POP  -  {param} 

PUSH  Tl  {return  value} 

JMP  T2  {resume  caller} 
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The  first  POP  saves  the  function's  value  in  temporary  register  Tl.  The  second  restores  the  callers 
environment  from  the  dynamic  link  (EP'IP  pair).  The  third  saves  the  caller's  resumption  address  in 
temporary  register  T2.  The  next  two  POPs  delete  the  function's  activation  record.  The  PUSH  instruc- 
tion puts  the  function's  value  back  on  the  top  of  the  stack,  and  the  indirect  JMP  through  T2  transfers 
control  back  to  the  caller. 

4.6    Function  Invocation 

The  code  sequence  for  the  function  application  '/   X*  is  as  follows: 

X 

SKIP  S 
f  X    =>     LOD 

SKIP  6  +  1 
CALL 

where  6  is  static  distance  to  /'s  environment  of  definition.  The  first  SKIP  moves  to  the  activation 
record  of  the  function  block  so  that  the  LOD  can  access  the  entry  address.  The  second  SKIP,  which 
goes  one  static  link  further,  accesses  the  environment  of  definition  of  the  function.  The  CALL 
macroinstruction  completes  the  invocation  process. 

The   CALL    macroinstruction    has   the    task   of  constructing   an    activation   record   for  the   callee   and 
transferring  control  to  the  callee.    This  is  accomplished  by  the  following  code  expansion: 

POPTl  {get  env.  of  defn.} 

POP  T2  {get  entry  address  } 

PUSH  Tl  {static  link  } 

PUSH  p  {callers  IP} 

PUSH  EP  {callers  EP} 

EP-SP-2  {callee's  SL} 

JMP  T2  {enter  function} 

LBL  p  {return  location} 

On  entry  to  the  CALL  macroinstruction  the  top  of  the  stack  is  the  environment  of  definition  of  the  cal- 
lee, the  second  on  the  stack  is  the  entry  point  address,  and  the  third  on  the  stack  is  the  actual  parame- 


ter  value: 


env.  of  defn. 


entry  point 


:tual 


The  first  two  are  saved  in  registers  Tl  and  T2.  The  actual  parameter  is  left  on  the  stack  to  form  the 
first  component  of  the  callee's  activation  record.  The  next  component  is  its  static  link  (whose  value 
was  saved  in  register  Tl).  Then  we  save  the  caller's  IP  (the  resumption  address  p)  and  EP  (which  was 
in  the  EP  register);  together  they,  constitute  the  dynamic  link  back  to  the  caller.  Finally,  EP—  SP— 2 
installs  the  callee's  activation  record  as  the  active  one,  and  the  indirect  JMP  through  T2  transfers  con- 
trol to  the  function.  The  LBL  p  of  course  defines  the  return  point  in  the  caller.  (Exercise  for  the 
reader:    Why  '-2'  in  'EP— SP— 2"?)  The  completed  activation  record  looks  like  this: 


ep 


•P 


SL 


par  am. 


4.7    Example 

Consider  the  following  simple  program: 

|letK  =   4 
'firnc  fac  n  = 

(if  (n  =    0) 
then  1 
else  (  n  x  fac  ( n  -  1 ) )   ) 

fac  K  1  1 


The  following  code  will  be  generated: 


LDC  4  local  value  K  =■    4 

ENTER  enter    let  K  = 

JMP  L3  skip  body  of  fac 

LBL  L4  entry  point  of  fac 

SKIP  0  access  formal  n 

LOD  fetch  value  n 

LDC  0  stack  0 

EQL  compare,  (n  =    0) 

JMPT  Ll  if  true,  skip  alternate 

SKIP  0  access  formal  n 

LOD  fetch  value  n  (to  multiply) 

SKIP  0  access  formal  n 

LOD  fetch  value  n  (to  subtract) 

LDC  1  stack  1 

SL  B  compute  actual  param  (n  —  1 

SKIP  1  access  defn  of  fac 

LOD  fetch  entry  point  address 

SKIP  2  access  fac's  env.  of  defn. 

CALL  call  fac  (n  -  1) 

MUL  multiply  n  by  result  of  fac 

JMP  L2  skip  consequent  of  if 

LBL  Ll  alternate  of  if: 

LDC  1  stack  1 

LBL  L2  end  of  if 

RETURN  return  from  fac 

LBL  L3  here  to  skip  over  fac 

LDC  L4  stack  entry  point  of  fac 

ENTER  enter  'func  fac  =  '  block 


SKIP  1  access  context  of  K 

LOD  fetch  value  of  K 

SKIP  0  access  context  of  fac 

LOD  stack  entry  point  of  fac 

SKIP  1  access  env.  of  defn.  of  fac 

CALL  call  fac  K 

EXIT  exit    func  fac  =  ' 

EXIT  exit  iet  K  =  ' 

Exercise  for  the  reader:    trace  the  execution  of  this  program  showing  all  stack  states. 
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5.    Code  Generation 

5.1  Introduction 

The    code    generator   is    like    Eval   and   Unparse,    except  that  we   change    the    domain    on    which    the 
evaluation  is  done: 

Unparse(£)  =^   "(3+5)" 

Eval(£,C)  == >    8 

CodeGen(£,C)  =>    <  LDC  [3],  LDC(5],  ADD> 
Notice  that  the  "value"  computed  by  CodeGen  is  a  list  of  target  machine  instructions. 

5.2  Code  Generation  Relations 

The  relations  required  for  code  generation   are  exact  analogs  of  the  Eval  and   Value  relations  in  the 
interpreter: 

.      CodeGen  (E,  C) 

request  code  generation  for  E  in  context  C 

Degree  (CodeGen,  2),  Domain  (expr,  1,  CodeGen),  Domain  (Context,  2,  CodeGen). 

.      Code  {U,  E,  C) 

U  is  the  code  for  E  in  C 

Function  (Code,  exprx Context,  code-list). 

5.3  Constants 

The  code  for  a  constant  is  simply  the  appropriate  LDC  instruction,  which  we  assume  to  be  generated 
by  the  function  Con: 

*CodeGen  [E,  C),  Con  (£),  LitVal  (  V,  E) 
=?>    Code  (<  Con[  V]  >  ,  E). 

Note  that  because  the  range  of  Code  is  defined  to  be  a  code  list,  it  is  necessary  to  return   Conj  V\   as  a 
one-element  list. 
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5.4  Applications 

We  need  an  additional  relation.  OpCode,  which  is  a  table  giving  the  target  machine  opcode  for  each 
primitive  operator.  This  relation  corresponds  to  the  Meaning  relation  of  the  interpreter  and  the  Tem- 
plate relation  of  the  un parser. 

.      OpCode  {F,  N) 

•  F  is  the  opcode  for  N 

•  Function  (OpCode,  string,  operation). 

The  analysis  rule  for  applications  must  request  the  code  generation  of  the  two  argument  expressions: 

*CodeGen  [E,  C).  Appl  (£),  Left  (A,  E) ,  Right  (  Y,  E) 
=t>    CodeGen  {X,  C),  CodeGen  (  Y,  C). 

The  synthesis  rule  catenates  the  code  sequence  for  the  arguments  with  the  appropriate  arithmetic  opera- 
tion found  in  OpCode: 

Appl  (£),  Op  [N,  E),  Left  (A,  E),  Right  (  Y,  E), 
*Code  (U,  X,  C).  *Code  (  V,   Y,  C),  OpCode  (F,  N) 
=^>    Code  [U   '  V  '  <  F>  ,  E.  C). 

Note  that  the  opcode   is  made  into  a  one  element  list  so  that  it  can  be  catenated  with  the  code  lists   U 
and    V. 

5.5  Conditionals 

The  analysis  rule  for  conditionals  requests  the  code  generation  of  the  three  parts  of  the  conditional: 

*CodeGen  {E,  C),  ConEx  (E),  Cond  (5,  E),  Conseq  (  T,  E),  Alt  ( F,  E) 
=>    CodeGen  (B,  C),  CodeGen  (  T,  C),  CodeGen  {F,  C). 

The  synthesis  rule  assembles  these  with  the  appropriate  jump  instructions: 
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ConEx  (E),  Cond  (B.  E).  Conseq  (T.  E).  Alt  (F,  E) 
*Code  (  U,  B,  C),  *Code  (  V,   T,  C),  *Code  (  W,  F,  C),  *Avail  (r,  w) 

=^.    Code  ( 

<JMPT!r]>     " 

W    ' 

<  JMP  [w],  LBL  [r]>    " 

r  * 

<LBL  [w]>  ,  £,  C). 

The  only  complication  is  that  unique  lables  r  and  w  must  be  generated. 

5.6    Block  Structure 

Contexts  will  be  computed  during  code  generation  just  as  they  are  during  evaluation.     However,   a 
name  is  bound  to  its  static  nesting  level  instead  of  its  value  (which  is  not  known  until  runtime). 

Variable  lookup  is  requested  by  the   Access  relation:   its  static  nesting  level  is  returned  in  the  Loca- 
tion relation. 

.      Access  [N,  D,  E,  C) 
access  N  in  D  for  E  in  C 
Function  (Access,  expr*  Context,  stringxContext). 

•      Location  (L,  E.   C) 

L  is  the  location  for  E  in   C 

Function  (Location,  exprx  Context,  integer). 

The  rules  governing  the  Access  process  are  exact  analogs  of  the  Lookup  rules  in  the  interpreter: 


*Access  (A,  D,  E,  C),  Binds  {D,  A.  L), 
==>    Location  (L,  E,  C) 

else  *Access  (A,  D,  E,  C),  Nonlocal  [D\  D) 
=->    Access  (A.  D\  £.  C) 

else  *Access  (A',  D,  E,  C) 

=>    Break  (''Undefined:  "   "A,  E,  C). 

5.7  VariabJes 

The  analysis  rule  for  variables  simply  request  that  Access  determine  the  variable's  location: 

*CodeGen  ( E.  C).  Var  (E),  Ident  (A,  E) 
=^>    Access  (A,  C.  E.  C). 

The  synthesis  rule  waits  for  the  static  distance  to  be  returned  in  Location,  and  incorporates  it  into  the 
appropriate  SKIP  instruction: 

Var  (£),  *Location  (L,  E,  C),  Binds  (C,  -  ,  K),  -Rator  (E.  -  ) 
=->   Code  (<  SKIP  :  A'-!!,  LOD>  ,  £,  C). 

The  condition  '  ^Rator  (E.  —  )'  is  a  bit  of  a  kluge;  it  prevent  the  activation  of  this  rule  on  variables  that 
happen  to  be  the  operator  of  a  function  application,  which  must  be  handled  differently.  A  runtime 
structure  that  supported  function-valued  functions  (and  variables)  would  eliminate  the  need  for  this 
kluge:    exercise  for  the  reader. 

5.8  Blocks 

The  analysis  rule  for  blocks  requests  code  generation  for  the  bound  value  and  the  block's  body. 

*CodeGen  (£,  C),  Block  (E),  BndVar  (A,  E),  BndVal  (X,  E) ,  Body  (B,  £), 
Binds  (C,  -  ,  A'),  *Avail  (D) 
=>    Context  (D).  Binds  ( D ,  A,  A  +  l),  Nonlocal  (C.  D ) ,  CodeGen  (X.  C),  CodeGen  (B.  D). 

The  bound  value's  code  is  generated  at  the  same  static  nesting  level  as  the  block  (A):  the  body  is  gen- 
erated at  a  level  one  greater  (A  +  l).     The  synthesis  rule   merely  catenates  the  code  sequences  with  the 
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ENTER  and  EXIT  instructions: 

Block  (£),  BndVal  (A,  £),  Body  (B,  £),  *Code  [U,  X,   C),  *Code  (  V.  B.  D).  Nonlocal  [C,  D) 
=>   Code  (  U   '  <  ENTER>    '  V  '<  EXIT>  ,  E,  C). 

5.9    Function  Definition 

Code  is  generated  for  a  function  definition  in  very  much  the  same  way  as  for  a  block.  The  analysis 
rule  requests  code  generation  for  the  body  of  the  function  and  the  body  of  the  function  block,  but  this 
requires  the  creation  of  two  new  contexts: 

*CodeGen  (£.  C).  FunDef  (£),  FunName  (F,  E),  FunFormal  (JV,  E) , 

FunBody  (B.  E) .  FunScope  (A'.  E) .  Binds  {C.  -  .  K).  *Avail  (D.  A) 
=->   Context  (D),  Nonlocal  (C,  D).  Binds  [D,  F,  K  +  1>  ),  CodeGen  (A.  D). 

Context  {A),  Nonlocal  [D,  A),  Binds  [A,  N,  K  +2),  CodeGen  (B,  A) 

The  context  D  represents  the  context  of  the  function  definition  block,  which  binds  F  to  static  nesting 
level  A'-rl  (i.e..  one  more  than  that  of  the  surrounding  context).  Code  for  the  body  A"  of  the  function 
definition  block  is  generated  in  this  context  D.  The  context  A  represents  the  context  of  the  function's 
body,  which  binds  the  formal  A  to  its  static  nesting  level  (A'^2,  i.e.,  one  more  than  D's).  A  is  the 
context  in  which  code  is  generated  for  the  function's  body;  notice  that  the  nonlocal  environment  of  .4 
includes  D,  thus  permitting  recursive  function  invocations. 

The  synthesis  rule  gathers  the  code  generated  for  the  function  and  block  bodies,  and  assembles  it 
into  the  complete  code  sequence: 

FunDef  (E).  FunBody  (B.  E),  FunScope  (A.  E) .  Nonlocal  (  C,  D). 
*Code  (  U,  B,  A),  *Code  (  V,  A,  D),  *Avail  [u,  4>) 
=^>    Code  ( 

<  JMP  \u],  LBL  \4>)>    '  U  ' 

<  RETURN,  LBL  [w], 
LDC  \<j>\,  ENTER>    *  V  * 
<EXIT>,  E,  C). 
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The  label  4>  is  the  function's  entry  point  (which  is  left  on  the  stack);  the  label  u>  is  for  skipping  over  the 
function's  body,  so  it  will  not  be  executed  until  it  is  called. 

6.  Function  Invocation 

For  function   invocations  the   analysis  rule   requests  code   generation   for  the   actual  parameter,    and 
lookup  for  the  function's  name: 

*CodeGen  (E.  C),  Call  (£).  Rator  [F,  E),  Rand  {X,  E).  Var  ( F) ,  Ident  {N,  F) 
=s>    Access  [N,  C,  F,  C),  CodeGen  (A',  C). 

Note  that  the  code  generator  requires  the  Rator  to  be  a  variable,  and  also  interprets  that  variable  as  the 
function's  name  (as  opposed  to  a  variable  pointing  to  the  function,  etc.). 

The    synthesis    rules    picks    up   from    Location    the    static    nesting    level    at   which    the    function    was 
defined,  and  uses  it  to  assemble  the  code  sequence: 

Call  (E),  Rator  [F,  E),  Rand  (A,  E),  "Location  (I,  F,  C).  *Code  (  V.  A,  C),  Binds  (C.  -  .  K) 
=*   Code  {V  '<  SKIP  \K-L],  LOD,  SKIP  [K-L+l],  CALL>  .  E,  C). 

The  first  SKIP  accesses  the  context  in  which  the  function  was  defined,  since  the  local  value  of  this  con- 
text is  the  entry  point  address  of  the  function:  see  5.9  Function  Definition  above  The  LOD  moves  the 
entry  point  address  to  the  top  of  the  stack.  The  second  SKIP  goes  one  further  than  the  previous,  which 
accesses  the  environment  of  definition  of  the  function.  The  actual  parameter,  entry  point  address  and 
environment  of  definition  are  left  on  the  stack  for  the  CALL  macroinstruction  (see  4.6,  Function  Invo- 
cation) . 
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APPENDIX  A:    Prototype  Programming  Environment 

The  following  is  a  loadable  input  file  for  the  code  generator  described  in  this  report.  Its  operation 
requires  the  PI-4  system  listed  in  Part  IV  [  MacLennan86bj ,  which  is  not  reproduced  here.  The  com- 
plete system  is  accepted  by  the  McArthur  interpreter  j  McArthur84] ,  which  differs  in  a  few  details  from 
the  fi  notation  used  in  this  report  (see  [MacLennan84] ).  A  transcript  of  a  test  execution  of  this 
environment  is  shown  in  Appendix  B. 


CODE  GENERATOR 


Reducing  Append  Function 


fn  api  LL| : 
if  LL=  Nil  ->    (j 
else  append    first    LLj ,  ap  jrest  j  LL]  ]  J ; 

!    Relations 


newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 
newrelation 


{"CodeGen"}; 

{"Code"}; 

{"Access"}: 

{"Location"}; 

{"OpCode"}; 

{'Cre  ate  ConEx  Code"}: 

{"CreateBlockCode"}; 

{"CreateFunDefCode"}; 

{"CreateFunDef2Code"} 
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newrelation  {"newlab"}; 
newrelation  {"LastLabel"}. 

!    Machine  Op  Codes 

!    Alias  procedure  to  define  niladic  opcodes: 

newrelation  {"alias"}. 

act  {<  <    if  *alias  (A,  s)  ->    define  {root,  s,  s},  A  (s);  >  >  }• 

alias  {"LOD"}; 
alias  {"ENTER"}; 
alias  {"EXIT"}; 
alias  {"CALL"}; 
alias  {"RETURN"}; 
alias  {"BREAK"}; 

!    Monadic  opcodes: 

fn  LDC    k  :    "LDC  "+    k: 

fn  JMP  [1]:    "JMP"^    1; 

fn  JMPT  ill:  "JMPT  "+    1; 

fn  LBL  |1  :    "LBL  "  +    1: 

fn  SKIP  (delta:  "SKIP  "  ^    int_str  |  delta] ; 

fn  PUSH    r  :  "PUSH  "  -    r; 

fn  POP  jrj:    'POP  "  +    r; 

!    Opcodes  used  in  operator  applications: 

OpCode  ("ADD",  "+  "). 
OpCode  ('SUB".  "-"), 
OpCode  ("MUL",  "x"), 
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OpCode  ("D IV",  »/»), 
OpCode  ("EQL",  "=  "), 
OpCode  ("GTR",  ">  "). 
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!    CODE  GENERATOR  RULES 

define  {root,  "CodeGenRules",  <  < 

!    Incomplete  Programs 

if  *CodeGen  (E,  C),  Undef  (E) 
->    Code  (|  BREAKj,  E,  C); 

!    Constants 

if  *CodeGen  (E.  C),  Con  (E).  Litval  (V.  E) 
->    Code  (   LDC    int_str  [Vj]j,  E,  C); 

!    Applications:    Analysis 

if  *CodeGen  (E.  C),  Appl  (E),  Left  (X,  E) ,  Right  (Y,  E) 
->    CodeGen  (X,  C),  CodeGen  (Y,  C); 

!    Applications:    Synthesis 

if  Appl  (E),  Op  (N.  E),  Left  (X,  E).  Right  (Y,  E),  *Code  (U,  X,  C).  *Code  (V,  Y.  C).  OpCode  (F,  N 

->    Code  (ap  !|U.  V,  [F]]],  E,  C); 

!    Conditionals:    Analysis 

if  *CodeGen  (E.  C).  ConEx  (E).  Cond  (B.  E) .  Conseq  (T.  E).  Alt  (F,  E) 
->    CodeGen  (B,  C),  CodeGen  (T,  C),  CodeGen  (F,  C); 

!    Conditionals:    Synthesis 

if  ConEx  (E),  Cond  (B,  E),  Conseq  (T,  E),  Alt  (F,  E), 
*Code  (U,  B.  C).  *Code  (V.  T,  C).  *Code  (W,  F,  C) 
->    CreateConExCode  (U,  V,  W,  E,  C,  newlab  {}.  newlab  {}); 
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if  *CreateConExCode  (U,  V,  W,  E,  C,  tau,  omega) 
->    Code  (ap  ( ( 

u, 

[JMPT  [tau]], 
W, 

iJMP  [omega],  LBL  [tauj], 
V, 
LBL  [omega]]]],  E,  C); 

!    Name  Lookup  Rules 

if  *Access  (N.  D,  E,  C),  Binds  (D,  N,  L) 
->    Location  (L.  E,  C) 

else  if  *Access  (N,  D,  E,  C),  Nonlocal  (Dprime,  D) 
->    Access  (N,  Dprime,  E,  C) 

else  if  *Access  (N,  D,  E.  C) 

->    Break  ("Undefined:  "4-    N.  E,  C); 

!     Variables.    Analysis 

if  *CodeGen  (E,  C),  Var  (E).  Ident  (N.  E) 
->    Access  (N,  C,  E.  C); 

!    Variables:    Synthesis 

if  Var  (E),  'Location  (L,  E,  C),  Binds  (C,  -  ,  K),  'Rator  (E,  -  ) 
->    Code  ([SKIP  [K-Lj,  LODj,  E,  C); 

!    Blocks:    Analysis 

if  *CodeGen  (E,  C),  Block  (E),  BndVar  (N,  E),  BndVal  (X,  E) ,  Body  ( B,  E),  Binds  (C,  -  .  K) 
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->    Create  Block  Code  (C,  N,  K,  X,  B,  newobj  {}); 

if  *CreateBlockCode  (C,  N,  K,  X,  B,  D) 

->    Context  (D),  Binds  (D,  N,  K+  1),  Nonlocal  (C,  D),  CodeGen  (X,  C),  CodeGen  (B.  D): 

!    Blocks:    Synthesis 

if  Block  (E).  BndVal  (X,  E) .  Body  (B,  E),  *Code  (U,  X,  C),  *Code  (V.  B,  D),  Nonlocal  (C.  D) 
->   Code  ( ap  [  I U,  j ENTERj ,  V,  [ EXIT]  ] ] ,  E,  C) ; 

!    Function  Definition:    Analysis 

if  'CodeGen  (E.  C),  FunDef  (E),  FunName  (F.  E),  FunFormal  (N,  E),  FunBody  (  B.  E).  FunScope  (X.  E 
Binds  (C,  -  ,  K) 
->    Create  FunDef  Code  (C,  F,  K,  X,  N,  B,  E.  newobj  {},  newobj  {}.  newlab  {}): 

if  *CreateFunDefCode  (C,  F,  K,  X,  N,  B,  E,  A,  D,  phi) 

->    Context  (D),  Nonlocal  (C.  D),  Binds  (D,  F,  K+  1),  CodeGen  (X,  D),  Context  (A),  Nonlocal  (D.  A). 
Binds  (A,  N,  K+  2).  CodeGen  (B,  A); 

!    Function  Definition:    Synthesis 

if  FunDef  (E),  FunBody  (B,  E),  FunScope  (X,  E),  *Code  (U,  B,  A),  *Code  (V,  X.  D),  Nonlocal  (C,  D) 
->    CreateFunDef2Code  (newlab  {},  newlab  {}.  U,  V,  E,  C); 

if  *CreateFunDef2Code  (omega,  phi,  U,  V,  E.  C) 
->    Code  (ap  j 

jJMP  jomegaj,  LBL  [phi]),  U, 

J  RETURN,  LBL  [omega], 

LDC  [phi],  ENTERj,  V, 

[EXIT]]],  E.  C): 

!    Function  Invocation:    Analysis 
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if  *CodeGen  (E,  C),  Call  (E),  Rator  (F,  E),  Rand  (X,  E),  Var  (F),  Ident  (N,  F) 
->    Access  (N,  C,  F,  C),  CodeGen  (X,  C); 

!    Function  Invocation:    Synthesis 

if  Call  (E),  Rator  (F,  E),  Rand  (X,  E),  "Location  (L,  F,  C),  *Code  (V,  X,  C).  Binds  (C.  -  ,  K) 
->    Code  (ap  [[V,  ISKIP  [K-L],  LOD,  SKIP  [K-L+  lj,  CALL]]],  E,  C); 

!    New  Label  Generator 

if  *newlab  (A),  *LastLabel  (n) 

->    A  ("L"-    int_str  in  ).  LastLabel  (n  -    1): 

>>}■ 

act  {CodeGenRules}. 
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!    Code  Generator  Commands 

newrelation  {"CodeGenPending"}. 

define  {root,  "CodeGenComRules",  <  < 

!    codegen  Command 

if  *Command  ("codegen"),  CurrentNode  (E),  CurrentContext  (C) 
->    CodeGen  (E,  C),  CodeGenPending  (E),  CommandPending  (E); 

if  Code  (V.  E.  C).  *CodeGenPending  (E).  *CommandPending  (-  ) 
->    displays  {"Code  generation  completed."}; 

!    showcode  Command 

if  'Command  ("showcode"),  CurrentNode  (E),  Code  (V,  E,  C) 
->    displayn  {V}; 

if  Command  ("showcode"),  CurrentNode  (E),  'Code  (V.  E,  C) 

->    displayn  {"No  code  available"}: 

>>}• 

act  {CodeGenComRules}. 

define  {root,  "CodeGenTests",  <  < 

if  *Test  (A,  10)  ->    {  Script  {[ 

"begin"    "let".  "K".  "#",  4,  "next",  'Tunc",  "fac".  V. 

"if",  "=  ".  "Var".  "n",  "next".  "#",  0,  "out",  "next",  "#",  1,  "next", 

"x".  "Var",  "n",  "next",  "call",  'Var",  "fac",  "next", 

"-".  'Var".  "n".  "next",  "#",  1.  "root",  "in",  "next",  "in",  "next", 

"call".  'Var",  "fac",  "next",  'Var",  "K",  'Voot".  "codegen",  Showcode" 

]}; 
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A  ('Test  done"); 

}; 

act  {CodeGenTests}. 

LastLabel  (0); 

if  *CurrentContext  (—  )  ->    CurrentContext  (newobj  {}) . 

if  CurrentContext  (C)  ->    Binds  (C,  "",  0). 

displayn  {"PI-5  System  Loaded."}. 
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APPENDIX  B:    Transcript  of  n    Session 

The  following  is  a  transcript  of  an  fi  session  illustrating  the  operation  of  the  prototype  programming 
environment  shown  in  Appendix  A.  The  assertion  'Script  {testscript}'  causes  the  commands  in 
testscript  to  be  executed  in  order.  The  nth  testscript  is  executed  by  'Test{n}\  Each  command  is 
printed  on  a  separate  line,  followed  by  whatever  output  is  generated  by  the  programming  environment. 
This  transcript  was  produced  by  the  McArthur  interpreter  [McArthur84  . 

%  omega 

OMEGA-1      11/30/84 

Use  Cntl-D  or  exit{}  to  quit. 

For  help,  enter  help{"?"}. 

To  report  a  bug,  enter  Bugs{}. 
newrelation  rule  activated. 

>  do{"Pl4.rul"}.  do{"Pl5.rul"}. 
PI-4  System  loaded 

OK 

>  PI- 5  System  Loaded. 
OK 

>  Test{l0}. 
...  begin 

...  K  let 

<  expr> 
...4  # 
...  next 

<  expr> 

...  fac  n  func 
...  if 
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<  expr> 


< 

expr> 

.  n  var 

.  next 

< 

expr> 

■0# 

.  out 

(n 

=    0) 

.  next 

< 

expr> 

•  1  # 

...  next 

<  expr> 
...  x 

<  expr> 
...  n  var 
...  next 

<  expr> 
...  call 

...  fac  va 
...  next 

<  expr> 


<  expr> 


...  next 


<  expr> 
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...  1  # 

...  root 

let    K  =   4 

[func  far  n  = 
(if  (n  =    0) 
then  1 
else  (n  x  fac  (n  -  1) 

<  expr>    j 
...  in 
4 
...  next 

func  fac  n  = 
(if  (n  =   0) 
then  1 
else  (n  x  fac  (n  -  1) ) 

<  expr> 

...  in 

(if  (n  =   0) 
then  1 
else  (n  x  fac  (n  -  1) ) 

...  next 
<  expr> 

...  call 
...  fac  var 
...  next 
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<  expr> 
...  K  var 
...  root 

let    K  =   4 

Ifunc  fac  n  = 

(if  (n  =   0) 
then  1 
else  ( n  x  fac  (n  -  1) )  ) 

fac  K  j 
...  codegen 

Code  generation  completed. 
...  showcode 

LDC  4,  ENTER,  JMP  L3.  LBL  L4,  SKIP  0.  LOD,  LDC  0,  EQL.  JMPT  Ll,  SKIP  0,  LOD, 
SKIP  0.  LOD,  LDC  1.  SUB,  SKIP  1,  LOD.  SKIP  2.  CALL.  MUL.  JMP  L2,  LBL  Ll.  LDC  1, 
LBL  L2.  RETURN,  LBL  L3.  LDC  L4,  ENTER,  SKIP  1,  LOD.  SKIP  0.  LOD.  SKIP  1.  CALL, 
EXIT.  EXIT 
>    exit{}. 

Goodbye. 

% 
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